COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	%Start Part 6 of 6 concep.tex
C00020 ENDMK
C⊗;
%Start Part 6 of 6 concep.tex
\beginsubSection{Modifying the Structure of Instances}

The first step modifies the structure of instances of the redefined
class to conform to its new class definition.  Local slots specified
by the new class definition that are not specified as either local or
shared by the old class are added, and slots not specified as either
local or shared by the new class definition that are specified as
local by the old class are discarded. The names of these added and discarded
slots are passed as arguments to {\bf update-instance-for-redefined-class}
as described in the next section.

The values of local slots specified by both the new and old classes
are retained. If such a local slot was unbound, it remains unbound.

The value of a slot that is specified as shared in the old class and
as local in the new class is retained.  If such a shared slot was
unbound, the local slot will be unbound.

\endsubSection%{Modifying the Structure of the Instance}

\beginsubSection{Initializing Newly Added Local Slots}

The second step initializes the newly added local slots and performs
any other user-defined actions.  This step is implemented by the generic
function {\bf update-instance-for-redefined-class}, which is called after
completion of the first step of modifying the structure of the
instance.

The generic function {\bf update-instance-for-redefined-class} takes
four required arguments: the instance being updated after it has
undergone the first step, a list of the names of local slots that were
added, a list of the names of local slots that were discarded, and a
property list containing the slot names and values of slots that were
discarded and had values.  Included among the discarded slots are
slots that were local in the old class and that are shared in the new
class.

The generic function {\bf update-instance-for-redefined-class} also
takes any number of initialization arguments.  When it is called by
the system to update an instance whose class has been redefined, no
initialization arguments are provided.

There is a system-supplied primary method for {\bf
update-instance-for-redefined-class} whose parameter specializer for
its instance argument is the class {\bf standard-object}.  First this
method checks the validity of initialization arguments and signals an
error if an initialization argument is supplied that is not declared
as valid.  (See the section ``Declaring the Validity of Initialization
Arguments'' for more information.)  Then it calls the generic function
{\bf shared-initialize} with the following arguments: the instance,
the list of names of the newly added slots, and the initialization
arguments it received.

\endsubSection%{Initializing Newly added Local Slots}

\beginsubSection{Customizing Class Redefinition}

Methods for {\bf update-instance-for-redefined-class} may be defined
to specify actions to be taken when an instance is updated.  If only
{\bf :after} methods for {\bf update-instance-for-redefined-class} are
defined, they will be run after the system-supplied primary method for
initialization and therefore will not interfere with the default
behavior of {\bf update-instance-for-redefined-class}.  Because no
initialization arguments are passed to {\bf
update-instance-for-redefined-class} when it is called by the system,
the {\bf :initform} forms for slots that are filled by {\bf :before}
methods for {\bf update-instance-for-redefined-class} will not be
evaluated by {\bf shared-initialize}.

\vfill\eject
Methods for {\bf shared-initialize} may be defined to customize class
redefinition.  See the section ``Shared-Initialize'' for more
information.

\endsubSection%{Customizing Class Redefinition}

\beginsubSection{Extensions}

There are two allowed extensions to class redefinition: 

\beginlist

\item{\bull} The \OS\ may be extended to permit the new class
to be an instance of a metaclass other than the metaclass of the
old class.

\item{\bull} The \OS\ may be extended to support an updating process
when either the old or the new class is an instance of a
class other than {\bf standard-class} that is not a built-in class.

\endlist

\endsubSection%{Extensions}

\endSection%{Redefining Classes}

\beginSection{Changing the Class of an Instance}

The function {\bf change-class} can be used to change the class of an
instance from its current class, $C\sub {\hbox{{\prmseven from}}}$, to a
different class, $C\sub {\hbox{{\prmseven to}}}$; it changes the
structure of the instance to conform to the definition of the class
$C\sub {\hbox{{\prmseven to}}}$.

Note that changing the class of an instance may cause slots to be
added or deleted. 

When {\bf change-class} is invoked on an instance, a two-step updating
process takes place.  The first step modifies the structure of
the instance by adding new local slots and discarding local slots that
are not specified in the new version of the instance.  The second step
initializes the newly added local slots and performs any other
user-defined actions. These two steps are further described in the two
following sections.

\beginsubSection{Modifying the Structure of the Instance}

In order to make the instance conform to the class $C\sub
{\hbox{{\prmseven to}}}$, local slots specified by the class $C\sub
{\hbox{{\prmseven to}}}$ that are not specified by the class $C\sub
{\hbox{{\prmseven from}}}$ are added, and local slots not specified by
the class $C\sub {\hbox{{\prmseven to}}}$ that are specified by the
class $C\sub {\hbox{{\prmseven from}}}$ are discarded.

The values of local slots specified by both the class $C\sub
{\hbox{{\prmseven to}}}$ and the class $C\sub {\hbox{{\prmseven
from}}}$ are retained. If such a local slot was unbound, it remains
unbound.

The values of slots specified as shared in the class $C\sub
{\hbox{{\prmseven from}}}$ and as local in the class $C\sub
{\hbox{{\prmseven to}}}$ are retained.

This first step of the update does not affect the values of any shared
slots.

\endsubSection%{Modifying the Structure of the Instance}

\beginsubSection{Initializing Newly Added Local Slots}

The second step of the update initializes the newly added slots and
performs any other user-defined actions.  This step is implemented by
the generic function {\bf update-instance-for-different-class}.  The
generic function {\bf update-instance-for-different-class} is invoked
by {\bf change-class} after the first step of the update has been
completed.

The generic function {\bf update-instance-for-different-class} is
invoked on two arguments computed by {\bf change-class}.  The first
argument passed is a copy of the instance being updated and is an
instance of the class $C\sub {\hbox{{\prmseven from}}}$; this copy has
dynamic extent within the generic function {\bf change-class}.  The
second argument is the instance as updated so far by {\bf change-class}
and is an instance of the class $C\sub {\hbox{{\prmseven to}}}$.

The generic function {\bf update-instance-for-different-class} also
takes any number of initialization arguments.  When it is called by
{\bf change-class}, no initialization arguments are provided.

There is a system-supplied primary method for {\bf
update-instance-for-different-class} that has two parameter
specializers, each of which is the class {\bf standard-object}.  First
this method checks the validity of initialization arguments and
signals an error if an initialization argument is supplied that is not
declared as valid.  (See the section ``Declaring the Validity of
Initialization Arguments'' for more information.)  Then it calls the
generic function {\bf shared-initialize} with the following arguments:
the instance, a list of names of the newly added slots, and the
initialization arguments it received.

\endsubSection%{Initializing Newly added Local Slots}

\beginsubSection{Customizing the Change of Class of an Instance}

Methods for {\bf update-instance-for-different-class} may be defined
to specify actions to be taken when an instance is updated.  If only
{\bf :after} methods for {\bf update-instance-for-different-class} are
defined, they will be run after the system-supplied primary method for
initialization and will not interfere with the default behavior of
{\bf update-instance-for-different-class}.  Because no initialization
arguments are passed to {\bf update-instance-for-different-class} when
it is called by {\bf change-class}, the {\bf :initform} forms for slots
that are filled by {\bf :before} methods for {\bf
update-instance-for-different-class} will not be evaluated by {\bf
shared-initialize}.

Methods for {\bf shared-initialize} may be defined to customize class
redefinition.  See the section ``Shared-Initialize'' for more
information.

\endsubSection%{Customizing the Change of Class of an Instance}

\endSection%{Changing the Classes of an Instance}

\beginSection{Reinitializing an Instance}

The generic function {\bf reinitialize-instance} may be used to change
the values of slots according to initialization arguments.

The process of reinitialization changes the values of some slots and
performs any user-defined actions.  It does not modify the structure
of an instance to add or delete slots, and it does not use any {\bf
:initform} forms to initialize slots.

The generic function {\bf reinitialize-instance} may be called
directly.  It takes one required argument, the instance.  It also
takes any number of initialization arguments to be used by methods for
{\bf reinitialize-instance} or for {\bf shared-initialize}. The
arguments after the required instance must form an initialization
argument list.

There is a system-supplied primary method for {\bf
reinitialize-instance} whose parameter specializer is the class {\bf
standard-object}.  First this method checks the validity of
initialization arguments and signals an error if an initialization
argument is supplied that is not declared as valid. (See the section
``Declaring the Validity of Initialization Arguments'' for more
information.)  Then it calls the generic function {\bf
shared-initialize} with the following arguments: the instance, {\bf
nil}, and the initialization arguments it received.

\beginsubSection{Customizing Reinitialization}

Methods for {\bf reinitialize-instance} may be defined to specify
actions to be taken when an instance is updated.  If only {\bf :after}
methods for {\bf reinitialize-instance} are defined, they will be run
after the system-supplied primary method for initialization and
therefore will not interfere with the default behavior of {\bf
reinitialize-instance}.

Methods for {\bf shared-initialize} may be defined to customize class
redefinition.  See the section ``Shared-Initialize'' for more
information.

\endsubSection%{Customizing Reinitialization}

\endSection%{Reinitializing an Instance}

\endChapter
\bye
%End Part 6 of 6 concep.tex